The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Global load balancing or “GLB,” distributes client access to servers across a distributed set of servers. The set of servers across which client access is distributed may, for example, be servers on a wide area network such as the Internet. For the purpose of discussion, examples shall be given in which GLB is used to distribute client access across servers on the Internet. The types of servers for client access may vary widely, and includes, but is not limited to, HTTP web servers, FTP servers, SMTP (mail) servers, other standard Internet protocol servers, or servers with proprietary protocols. As used herein, the term “server” shall mean any type of server listed previously.
Many GLBs use a variety of active and passive monitoring techniques to generate a complex map of the Internet. Based upon this map, the GLB makes traffic routing decisions to connect a client to the “closest” server. As used herein, “close” does not necessarily mean basing the determination only on geographic proximity. As used herein, a “close” server is a server that results in the fastest connection to the client. Thus, if a server that was located 100 miles away were slower for the client to reach than a server located 200 miles away because of heavy network congestion, then the GLB would route the client to the server 200 miles away.
The most common form of global load balancing is based upon domain name service (“DNS”) which is illustrated in FIG. 1. In the system illustrated in FIG. 1, two or more data centers, which may be located in geographically distinct areas, contain large numbers of servers capable of hosting web applications. A client 105 wishes to connect to a web application that is hosted by each of two data centers. For example, one data center that hosts the web application might be located in New York 103 and the other data center that hosts the web application might be located in San Francisco 101.
Internet service providers (“ISPs”) may use a centralized local name resolver, also called a recursive DNS resolver, that resides within the ISP's network and communicates with the ISP's users to service their DNS requests. The client communicates with the local name resolver, and then the local name resolver determines where to find the information that the user requested. An authoritative DNS resolver of a domain receives the request from a local name resolver and sends the local name resolver the IP address of the domain. An authoritative DNS resolver of a domain is a server that resides within and maintains data for the network of a domain. GLB may be a part of the authoritative DNS resolver or may be separate from the authoritative DNS resolver. As used herein, the term “resolver” shall refer to the authoritative DNS resolver, with which a GLB may or may not be a part.
For example, in FIG. 1, client 105 sends a request 111 to local name resolver 107 comprising a domain name, such as “www.sampledomain.com.” The local name resolver 107 asks 115 the authoritative DNS resolver 109 that is the owner of “www.sampledomain.com,” for the IP address of “www.sampledomain.com.” The authoritative DNS resolver (and GLB) for “www.sampledomain.com” 109 responds to the local name resolver 107 with an IP address of a data center based upon the information in the map generated by the GLB. If the GLB detects high traffic to the data center in San Francisco 101, then the GLB might send the connection to the “closer” data center in New York 103, even though geographically, the data center in New York 103 is much farther away from the client 105. The local name resolver 107 sends the IP address of the data center in New York 103 to the client 105. Then, and only then, the client 105 connects 119 to the data center in New York 103 and does not connect 117 to the data center located in San Francisco 101.
Upon changes in network topology or connectivity, such as fiber cuts, equipment problems, capacity issues, netblock migration, or human intervention, the Internet map needs to be rebuilt, often from ground up. Depending upon the protocols and algorithms used to create or update the map, this process could take a significant amount of time. Due to the dynamic nature of internet topology, the GLB may have difficulty maintaining a full, accurate model of the internet. The resulting inaccuracies in the map may lead to incorrect routing decisions, which may have severe implications for client to server performance. As a result, there is a need for techniques that provide the “closest” connection to a server that are not based upon generating and maintaining a map of the internet with DNS-based GLB.